Date: Mon, 20 Sep 93 04:30:16 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V93 #47 

To: Ham-Digital 


Ham-Digital Digest Mon, 20 Sep 93 Volume 93 : Issue 47 


Today's Topics: 
"Digital" to Europe; your thoughts on the best ways? 
Is there a FAQ? I wanna talk to my robot ... 
NF3I -- Scott Rosenfeld 
Packet/Internet gateway? 
packet radio & distance education (2 msgs) 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Mon, 20 Sep 1993 01:57:31 GMT 

From: world!slm@uunet.uu.net 

Subject: "Digital" to Europe; your thoughts on the best ways? 
To: ham-digital@ucsd.edu 


Greetings! I hope some folks here on the net can offer some suggestions, 
advice, and opinions on the following *‘problem.'' 


I am in New England, and want to send a digital message to a friend in 
Slovenia. Alas, he has no Internet connection :-) ... but he is on 
““regular'' (i.e. AX.25) packet. 


I have been simply writing my messages on my local BBS (K1UGM), which 
forwards them to a regional hub in New Hampshire, which then ships them via 
AMTOR to a system in Croatia (which is down a fair amount), which then 
forwards themto Slovenia. This can take less than a day with a lot of luck; 
it also can (and often has) take longer than postal mail. 


I'm trying to figure out what might be faster and still reliable, and have 
been thinking about the following: 


* TCP/IP. I hear some folks are experimenting with **‘encapsulating'' TCP/IP 
ham messages in Internet to get them ‘‘over the pond,'' which seems nice, 
fast, and reliable (no worries about solar flares). However, my friend on the 
other side isn't on TCP/IP (actually, neither am I yet, although I will make 
the effort to set up and learn if it seems it will be worthwhile). Could 

this still work? Are there gateways I could use to send messages reasonably 
fast to Europe? Could I realistically (not awfully slow) telnet via 

TCP/IP into a BBS in Europe to forward a message? Can I send a TCP/IP 

message here and have it get reasonably fast to an AX.25 system in Europe? 


* Routing AX.25 through NY. Most international traffic in New England is 
routed through the hub in NH. However, from what I've read, it looks like 
New York has a very nice gateway into London; and WA2NDV forwards **twice 
hourly.'' I tried getting into WA2NDV myself via 2m AX.25; but through 

4 digipeaters, it is too slow to be worthwhile. What about sending a 
message on my local 2m AX.25 board and somehow routing it to go through 
WA2NDV? Can I do this--tell a message on a BBS how I want it routed? 
Would I then I need to know an entire path also from London to Slovenia? 
[Please excuse me if these questions seem painfully 

elementary, but I'm curious and don't know] 


*x AMTOR myself to 9AQAPL. I've never used AMTOR but have the capability 
(PK-232). Perhaps it's worthwhile to send my mail myself to 9AQAPL via 
AMTOR, instead of having the NH hub do it for me? Could I sign onto the 
system myself and send a message to forward somewhere else, like on a packet 
BBS? 


* Internet/packet gateway? There's such a thing in the States, I know; but 
is it possible to send an Internet message to a system in Europe that would 
then put it back into the packet system there? 


*x Any other ideas? (i.e. HF packet, which I heard is terribly slow, or 
something else) 


Thanks for your thoughts. Although what I have been donig (using the local 
2m BBS) has been working, I'd really like to know more about this than just 
posting on a local BBS and having the messages eventually arrive, "somehow, " 
to their destination. 


73, Sharon KC1YR 


electronic address: slm@world.std.com 


Date: Sun, 19 Sep 1993 15:22:53 GMT 

From: swrinde! gatech!kd4nc!ke4zv! gary@network.ucsd.edu 
Subject: Is there a FAQ? I wanna talk to my robot ... 
To: ham-digital@ucsd.edu 


In article <m900s8INNptf@tofu.cs.utexas.edu> cpg@cs.utexas.edu (Carlos M. Puchol) 
writes: 

>Is there an FAQ for this group? I want to get started and 

>I really get lost with so many acronyms, the most famous of 

>all, TNC. 


Yes, there's a FAQ, but I'll address the "what's a TNC" question 
right away. TNC stands for Terminal Node Controller; yes packet 
started before personal computers were common and dumb terminals 
were the rule. So we had a dumb terminal connected to this little 
box with a microprocessor and a modem in it. The microprocessor 
executed firmware that did the PAD function, Packet Assembler/ 
Disassembler, channel management, and user interface. The modem 
did the Bell 202 half duplex tone encoding/decoding. 


Somewhat unfortunately, TAPR came along and offered a very good 
TNC, the TNC2, that was cheap, reliable, effective, and licensed 
to several commercial manufacturers. This had the effect of 
freezing a by now obsolete paradigm in silicon and copper. So 

we still use TNCs today despite the fact that we almost all now 
have real computers on our desks, and 1200 baud is painfully 
slow. The user interface in the TNC was designed to work with 

a human at a terminal. It's not well suited to automatic computer 
control. So other interfaces have been kludged onto the firmware. 
Things like the host mode and KISS modes you'll read about here. 


Today the TNC is becoming obsolete from two different directions. 
First, the TNC hardware can't keep up with the faster modems now 
available. And second, PC software that does the functions of the 

TNC firmware is now widely available. Faster speed is being addressed 
by special dedicated plugin hardware like the Gracillis boards or 

the Ottawa PI cards. On the low speed end, Baycom style simple 

modems and software are gaining ground. But there's still a huge 
installed base of TNCs, and systems have to maintain compatibility 
with this older technology to gain sufficient user base. 


Gary 


Gary Coffman KE4ZV |"I£ 10% is good enough | gatech!wadmei! ke4zv! gary 


Destructive Testing Systems | for Jesus, it's good | uunet!rsiatl!ke4zv! gary 
534 Shannon Way | enough for Uncle Sam."| emory!kd4nc!ke4zv! gary 
Lawrenceville, GA 30244 | -Ray Stevens 


Date: Sun, 19 Sep 1993 18:06:25 GMT 

From: vtserf.cc.vt.edu!agf.async.vt.edu!aflorenc@uunet.uu.net 
Subject: NF3I -- Scott Rosenfeld 

To: ham-digital@ucsd.edu 


Attention Scott Rosenfeld, NF3I, in Maryland. Please E-mail me. 


Adam Florence 
aflorenc@vt.edu 


Date: 19 Sep 93 19:02:19 GMT 

From: ogicse!emory !wupost!howland.reston.ans.net!vixen.cso.uiuc.edu! 
moe.ksu.ksu.edu! cbr600@network.ucsd.edu 

Subject: Packet/Internet gateway? 

To: ham-digital@ucsd.edu 


I was just reading through the newsgroups this evening, and in the previous post 
I saw something about packet/Internet gateways? I have always been fascinated 
about the posibility of this, and I wondered how it was accomplished...also, how 
I would go about sending a message through this sort of gateway to have it arrive 
to another packet user, or vice versa...although I am a licensed amateur, 
(no-code variety), I do not as of yet have a TNC or 2-meter rig to run packet 
radio...any help on this subject would be greatly appreciated. 


Jeremy L. Utley 
cbr600@ksuvm (Bitnet) 


| I didn't do it, nobody saw me 
| 

| cbr600@matt.ksu.ksu.edu (Internet) 

| 

| 


do it, You can't prove any- 
thing. - Bart Simpson 
NOYAX@WZOM.KS.USA.NA (Ham Radio) 


Date: 20 Sep 93 22:20:38 GMT 

From: koriel!sh.wide!wnoc-tyo-news!nec-tyo!necspl!ideon!mike@ames.arpa 
Subject: packet radio & distance education 

To: ham-digital@ucsd.edu 


>>>>> On 18 Sep 93 03:34:40 JST, bapgar@uoguelph.ca (Bill Apgar) said: 


> I have read at least one article which discusses the use of packet 

> radio in Africa and elsewhere to support or provide distance education 
> programs. I am interested in knowing if any reader(s) are aware of, 

> or participating in such initiatives or programs, and further if any 

> involve radio amateurs in either hosting nets or relaying. 


I have a _little_ background in the technology (enough to handle some 
technological concepts). I am researching farmer/rural access to 
agricultural information through telecommunications technologies and 
would like to include packet/digital radio in my overview. 


VVV Vv 


does this impose for those who would like to 'receive' packet radio 
broadcasts, but do not have digital operator's licencing? Several years 
back I heard that because a packet requires echoing back from the 
receiver, the receiver itself must therefore also be a transmitter, 

and in North America at least, the DOC and FCC would require any 

radio transmitter to be appropriately licenced? Or is in fact, as 

I have also heard, the _operator_ who must be licenced, not the 
equipment, therefore implying that as long as a licenced operator is in 
the room (or on site), a packet-radio transceiver can be '‘used' by 
other parties in the room? 


VVVVV VV VV VV 


One can set up a receiver only and monitor packet radio traffic very 
easily but in my understanding amateur packet radio would not be adequate 
for "broadcasting" as is because a) amateurs cannot broadcast and 
therefore it is not designed that way and therefore b) the main 
protocols used, TCP/IP and AX.25 assume two-way communication and 
error correction. I would assume the main problem would be error 
correction, i.e. if the "listener" receives a bad packet it cannot 
broadcast a message back saying "send it again". That being said I 
cannot see it would be difficult to adapt the protocol side to achieve 
a broadcast mode like RTTY news stations [ come to think of it do any 
national amateur organisations broadcast packet news ? ]. 


Licensing would be commercial/government and depend on case and 
country. Given the low entry cost and ease of maintenance, packet 
does seem a very attractive technology in less developed countries. 


Mike Collinson 

Assistant Manager, Product Engineering Dept., UX Software Development Div., 

NEC Corporation, Daito Tamachi Building, 14-22 Shibaura 4-Chome, 

Minato-ku, Tokyo 108, JAPAN 

Email: mike@uxp.bs2.mt.nec.co.jp Fax:+81-3-3456-6675 
Tel: +81-3-3456-7451 


Additionally -- since packet radio involves transceiving, what limitations 


Date: 20 Sep 1993 09:59:05 GMT 

From: mcsun!Germany.EU.net! fuhain£.fernuni-hagen.de!mac-6.fernuni-hagen.de! 
user@uunet.uu.net 

Subject: packet radio & distance education 

To: ham-digital@ucsd.edu 


In article <27d000$6kb@nermal.cs.uoguelph.ca>, bapgar@uoguelph.ca (Bill 
Apgar) wrote: 


> Additionally -- since packet radio involves transceiving, what limitations 
> does this impose for those who would like to 'receive' packet radio 
> broadcasts, but do not have digital operator's licencing? 


If you want an error-free point-to-point connection both stations have to 
transmit (at least for acknowledge/reject signals). But you can still 
broadcast packages (everybody can receive them) or arbitrarily many 
stations can monitor 

a single point-to-point link. Of course, then you risk loss of packages at 
some 

stations. 

For broadcasting without error-recognition there are better techniques than 
packet radio. The reason why is that packet uses a checksum on packages. So 
a single bit error causes at least one package to be lost. Depends on the 
packet size how much data this is. Other techniques loose only this bit. So 
only a single character (or pixel, if you use fax) is lost. 


Bernd (meyer@fernuni-hagen.de, DB6AG) 


Date: Sun, 19 Sep 1993 12:19:05 GMT 
From: mcsun!sun4nl!hacktic!utopia.hacktic.nl!globv1.hacktic.nl!peter@uunet.uu.net 
To: ham-digital@ucsd.edu 


References <275n£7INN6nh@gap.caltech.edu>, 
<1993Sep16.132657.1519@globv1.hacktic.nl>, 
<1993Sep18 . 032116 .25330@gsm001.mendelson. com> 
Subject : Re: Packet on a Unix box? 


gsmlrn@gsm001.mendelson.com (Geoffrey S. Mendelson) writes: 


>>I hope that you hams don't jump in on me for publicly stating that I'm a CBer. 
>>Some hams xhatex the CB. On the other hand I meet hams on the CB packet net 
>>every day, I guess not completely without reason. Anyway, you wouldn't want to 
>>scare away a future colegue who is studying hard to pay of his sins, would 


>>you??? ;-) 


>If I were in your country I would use CB for packet. IMHO It makes no 
>sense to use the ham bands there. 


It does make sense. Because the CB too has it's restrictions. The amateur bands 
are better organized, the CB is a complete anarchy. There are almost no NOS 
users in a radius of more than 30km! A great disadvantage. ;-) I was the first 
in fact in this part of the country. The situation on the amateur bands seems 
much better. The few CB people I spoke who knew NOS, knew it from the amateur 
bands. Another disadvantage is that experimenting with CB sets makes them 
illegal. Modifications are not allowed and that limits the possible packet 
speeds to 1200 bps and 2400 bps. About half of the regular availlable CB sets 
can do 1200 bps and only very few CB sets can do 2400 because of the bandwidth. 
The power is legally limited to 4W and the only modulation allowed is FM. 
(Although that "legally" doesn't have any meaning for many people; 100W 
linears and SSB sets are not very rare...) And I didn't mention the xssholes 
who deliberatly push their mikes on the packet channels... 


You see, it still makes sense. 


Groetjes, 
Peter Busser 


Linux, the choice of a GNU generation. 


End of Ham-Digital Digest V93 #47 
KKKKKKKKKKKKKKKKKKKKKEKKEKRKE ARK K IK 


